Automation equipment has, in recent times, changed not only many industrial sectors but also a number of aspects of daily life. The significance of the changes extends from office equipment, to the processing and manufacturing industries, to logistics and building technology. The term “automation equipment” encompasses complex decentralized peripherals (I/O modules, measuring transducers, drives, valves, operator terminals and the like), as well as relatively simple actuators and sensors with binary signal systems.
The benefit that these types of automation equipment provide is determined in part by their ability to communicate with other pieces of equipment. It is usually necessary to connect the pieces of equipment to one another by means of bus systems. In this context, it has proven useful to control the data traffic on the bus by means of one or more units, referred to as master units. In contrast, other units, referred to as slave units, do not themselves have authorization to access the bus, but rather only output received data or transfer registered data to the master when requested by a master unit. These slave units can therefore also be referred to as “passive stations” (in contrast to “active” master units).
In the field of automation technology, programmable logic controllers (PLCs) are used primarily for processing data. Within the bus system, they often also assume the functionality of the master, either directly or in conjunction with specific assemblies. A PLC then carries out a control application for the automation equipment and also controls the necessary data traffic on the bus system. However, as a result of the rapid spread of generalized computing equipment, it is often advantageous to make it possible to use commercially available, general purpose computers, such as personal computers (PCs). In this way, not only is it often possible to use existing hardware at the same time for a number of tasks, but, when it is necessary to acquire new equipment, it is possible to profit from the favorable cost/benefit ratio of standard hardware. At the same time, it is possible to integrate the execution of a number of tasks (for example control, operation, monitoring and diagnostics) in one device, which can lead to additional cost savings. Finally, in this way it is also possible to achieve greater functional flexibility because the associated control applications can usually be programmed and reconfigured more easily in a typical PC environment.
Communication between the processor of a control unit and individual pieces of automation equipment usually occurs via a bus interface that transmits individual data packets over the bus system to the automation equipment and that can detect and read incoming data packets. For security reasons, the bus interface is generally programmed in such a way that, in an emergency, it independently places the data traffic on the bus system in a secure state. This is accomplished by placing the individual pieces of automation equipment in a non-hazardous basic state and by terminating communication with these pieces of automation equipment. Such security switching is necessary for two reasons.
First, the network of automation equipment must be kept from entering an uncontrolled state in the event of a failure of the control unit. In order to detect such an emergency, a watchdog mechanism is usually provided: an emergency is always assumed to have occurred as soon as the processor fails to transmit a signal to the bus interface during the course of a preselected period (typically a few seconds).
Second, it is typically necessary to have an additional protection mechanism that is sensitive and that acts even during a significantly shorter time period. The bus interface monitors for a signal, imposed by the processor, inhibiting access by the bus interface. Because the bus interface is generally forced by the protocol on the bus to transmit and receive data very quickly when required, it is also necessary to monitor effectively for signals, such as the inhibit signal described above, within a time frame of a few microseconds. If there is a relatively long inhibit imposed on the data access, delays on the bus system can lead to protocol errors that, in turn, can lead to data losses and should therefore be avoided.
The inhibiting of the data access described above occurs, in particular, in the context of a commonly-occurring and comparatively simple computer architecture that is commonly found and that serves to transfer data from the processor to the bus interface. In particular, there may be a memory module between the processor of the control unit and the bus interface. The memory module, which can be a multi-port storage device, can be written to and read from (e.g., dual port RAM) both by the processor and by the bus interface, and serves to transfer orders to the bus interface, as well as data packets that are to be transmitted to the pieces of automation equipment. The transfer from the control unit to the bus interface can be carried out by means of the following three steps:    1. The processor inhibits the bus interface;    2. The processor changes the data n the memory module that can be accessed on two sides; and    3. The processor releases the interface.
For the reasons described above, fatal errors may occur if the phase for which the bus interface is inhibited lasts longer than a few microseconds. However, this is the case particularly if an interrupt in the program execution occurs during the steps 1-3, and the program does not continue to step 3 until after another routine has been executed.
Such interrupts, though, are quite common in modern operating systems, especially in operating systems that support multitasking. In such systems, it is possible to conceive of different scenarios in which there may be a “controlled” program interrupt, that is to say one that is desired by the architect of the operating system. In the case of operating systems that are capable of multitasking, the available working time of the processor is distributed among the various applications, and the processor of the data processing system changes from one application to another with a specific timing in accordance with an external timer. If the processor receives such a time signal during the execution of the control application of interest, its execution is interrupted and the processor transitions to processing a different application. The processor, however, can also be made to execute certain other tasks and to interrupt the connection to the bus interface in response to other external events (for example the movement of the mouse cursor). Owing to the customary security switching, this leads to emergency securing of the data traffic on the data bus, and can thus lead to complete deactivation of the entire system, in particular during the data transfer operation (the three steps described above).
The possibilities for the interruption of a specific application described above result from a principle that underlies modern operating systems: In such systems the individual applications are generally not given authorization to access specific hardware components directly (user mode). In particular, the operating system prevents, at least temporarily, all processor commands from being called by the control application. This authorization is granted only to the operating system itself (kernel mode). In this way, not only is a protective barrier set up between the individual applications, which are executed in parallel, but it is also possible to prevent an erroneous program configuration of the individual application bringing about error states of the entire system that can no longer be corrected. In operating systems that have this protection mechanism, the individual applications lose the ability to react to current tasks in a guaranteed time interval. Nevertheless, as a result of the introduction of the kernel mode, it is no longer possible to predict the reaction times and processing times of an application. These operating systems are, therefore, also referred to as non-real-time-capable operating systems.
Expressed in abstract terms, the problems involved in the operation of a control application with a data processing system can be traced back to a conflict between two protection systems. In order to be able to actuate pieces of automation equipment reliably, it is necessary for contact to be maintained between the control application and the bus interface via the processor and for this contact not to be interrupted randomly. However, this contradicts a basic concept of modern operating systems that distinguishes between the user mode and the kernel mode and that does not allow a control application running in a user mode to have complete and permanent access to the processor.
Two concepts permit these problems to be avoided and the control application to bypass the protection scheme of the operating system in a particular case.
First, a number of what are referred to as generic device drivers are provided that permit an application to have direct access to the storage areas of the bus interfaces. This allows restrictions due to the operating system to be largely limited, though the problem of loss of control due to external events remains. As in the past, a control application can be interrupted by a change of application brought about by the operating system, or by the processing of an operating system routine.
Second, the control application itself can be programmed as a device driver. Device drivers control devices in a computer operating system and generally have extensive access privileges to all the devices of the operating system. In particular, device drivers can also inhibit the execution of hardware and software interrupts. As a result, such a control application is not subject to restrictions by the operating system, and direct access to the bus interface as a hardware component is ensured. The scope of the privileges of the application programmed as a device driver is preferably dimensioned in such a way that there is no decisive loss of security as a result of bypassing the security systems of the operating system. However, there may also be compensation for the loss of security by virtue of the fact that the number of applications running on the control unit is reduced. The disadvantages of this solution lie in the fact that device drivers can be configured in modern operating systems only at very high cost, which also requires extensive development, testing and maintenance measures. In addition, the calling of a device driver from an application takes a long time, which rules out this option for many applications.